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Abstract 



In this paper we will discuss the design of abstract firewall model along 
with platform-independent policy definition language. We will also discuss 
the main design challenges and solutions to these challenges, as well as 
examine several differences in policy semantics between vendors and how 
it could be mapped to our platform-independent language. We will also 
touch upon a processing model, describing the mechanism by which an 
abstract policy could be compiled into a concrete firewall policy syntax. 
We will discuss briefly some future research directions, such as policy 
optimization and validation. Keywords: firewall, policy, NAT, fwbuilder, 
security, rules 
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1 Introduction 



Presently, firewall administrators are often required to manage multiple firewall 
platforms from different vendors. Each of these platforms has its own language 
to describe firewall policies. Besides syntax differences, firewall policy models 
also vary from vendor to vendor. If we make a parallel to programming lan- 
guages, a firewall administrator is required to learn multiple assembly languages. 
One possible solution is the introduction of a high-level, platform-independent 
firewall policy description language which could be compiled into representa- 
tions specific to particular platforms. This approach relieves the burden on 
firewall administrator of learning the low-level details of multiple firewall plat- 
forms. Additionally, it helps to eliminate large groups of trivial errors which 
a human could make during policy configuration, by allowing a user to work 
with higher level abstractions without being burdened by low-level policy syn- 
tax details. Having a platform-independent policy representation will also allow 
the user to develop a class of cross-platform tools for managing, analyzing, and 
validating such policies. We believe that our approach will allow administrators 
to increase system security by reducing the chance of human error. 

The ideas described in this paper are implemented in a successful open 
source project called Firewall Buildcr[lO]. It currently supports five firewall 
platforms and is included in major Linux distributions. Firewall Builder al- 
lows the user to create and edit policies of an abstract firewall expressed in a 
platform-independent language. The project provides convenient GUI for edit- 
ing firewall policies. The abstract policy uses a set of provided policy compilers 
to compile into policy files for concrete firewall platforms. In this paper we have 
focused on abstract firewall models and policy compilation. We refer readers to 
related documents on Firewall Builder user interface[ll], API, extensibility [14], 
etc. 

This paper is organized as follows: In section 2 we wil describe the Abstract 
Firewall model we are using. In section 3 we will discuss some examples of 
platofrm-specific differences to illustrate the kinds of problems we are solving. 
Then, in section 4, we will discuss some processing techniques we have used. 
Finally, in section 6 we will cover some of the possible directions of future 
research. 
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2 Abstract Firewall 



Firewall Builder presents a user with a Synthetic Model of a firewall, in which 
we can combine features supported by various firewall platforms. We also made 
some assumtions about the semantics of some rules, which are normally also 
platform dependent. 

When working with Firewall Builder, the user only needs to know this ab- 
stract firewall model. The user defines policy for this imagninary abstract fire- 
wall, and Firewall Builder's policy compiler translates it to the model of the 
concrete firewall where it will be actually deployed. 

2.1 Data Model 

We use an object model to represent various networking and security concepts 
used in configuring firewalls. User data is saved in files with .fwb using syntax 
described in section 2.2. Objects are organized into Libraries. Each file is a col- 
lection of such libraries. Typically there is at least one library of objects created 
by the user. Additionally, there is a library of standard objects provided with 
Firewall Builder which includes definitions of standard objects (such as a list of 
standard address ranges for private networks per RFC 1918[12]). When used in 
a business environent, the company may supply some libraries of company- wide 
objects to be used by all departcmcnts. 

The objects could be rougly split into several categories: 

2.1.1 Basic Networking Objects 

This category includes some basic objects representing common concepts used 
in Networking. Some of them are: 

IPv4 Address Internet Protocol (IP) version 4 address 

IP Service IP service, defined by protocol number and some options like loose 
source rote and record route 

UDP Service UDP service is defined by source and destination port ranges. 

TCP Service TCP service is defined by source and destination port ranges 
and some flags. 

ICMP Service ICMP service is defined by ICMP type and JCMP code 
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Physical Address Data link layer address, such as Ethhernet MAC address 
or Frame Relay Data Link Connection Identifier (DLCI). 

Time Interval Allows specify time period. Time intervals are commonly used 
to specify time-based firewall policies. It could be expressed either in 
terms of absolute date and time specifications, or in terms of week days 
(e.g. from Monday to Friday) 

2.1.2 Hosts, Firewalls, Policies 

More complex objects are Hosts. They represent network nodes (servers, work- 
stations, routers, IP printers, etc.). Hosts can have multiple interfaces with 
static or dynamic IP addresses. 

A Firewall is a special kind of host, which will be running firewall software 
and could be configured using Firewall Builder. The user must specify what 
OS platform and firewall software they are using (some platforms allow the user 
to select from several firewall packages). For firewalls, the user can define a 
Firewall Policy and iVAT Rules. 

Firewall Policy consists of a set of firewall rules. Each rule has a source and 
destination, service, interface, direction, time and an action. Rule-matching 
semantics will be explained in Section 2.3. 

NAT Rules specify how the firewall host performs network address transla- 
tion, changing sources and destinations of passing packets. 

2.1.3 Utility Objects 

Objects in these categories are various convenience objects, representing higher- 
level concepts which are easy to use when describing firewall policies. 

Address Range Range of IPv4 addesses. Specified by first and last address. 

Address Table List to IPv4 addresses which is specified in an external file 
that can be loaded at policy compile time, or at the time of deployment of 
generated firewall policy, depending on the option configured in the Ad- 
dress Table object. Such lists are commonly used to maintain dynamically 
updated black lists of spammers or intruders. 

Groups Various objects could be combined into named groups for the conve- 
nience of referencing them as such in policy rules. Users typically group 
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hosts, IP addresses, services and time intervals. Groups are "typed". That 
means that groups can contain only objects of the same type. 

2.2 Syntax 

The policy is expressed as an Extensive Markup Language (XML [6]) document. 
The grammar of this document is specified as a Document Type Definition 
(DTD) file. The DTD file for the current version is shown in Appendix A. 

Each object has an unique id attribute. This attribute is used to establish 
references between objects. 

Here are some examples, to illustrate the syntax we use. First, some simple 
objects: 

Listing 1: Network Object 

<Network i d =" id47505CE816470" namc=" officcLAN" addrcsa=" 10.86.81.0" nctmask=" 
255.255.255.0"/> 



Listing 2: UDP Service Object 

<UDPService id=" id4 75 5 D 2 1 64 70 " namc=" MyScrvic" d S t _r a n g e _ e n d =" 92 " d s t _r a n g c _ s t a r t = 
"90" srerangcend-' 70" s r c _ r a n g c _ s t a r t =" 3 " /> 

Now let us take a look at a firewall with a simple single-rule policy 1 , shown 
on listing 3. 

Listing 3: Firewall Object 



2 
3 



5 
6 
7 



9 
10 
11 

12 
13 
14 
15 
16 
17 
18 
19 
20 

1 for clarity, some non-essential attributes and elements were omitted 
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<Firewall host.OS=" Hnux24" id = " i d 4 7 5 5 D 5 1 6 4 7 " name=" MyFirewall" platform=" 
iptablcs"> 

<Interface dyn=" False" id ="id47505D0B 16470" name=" i f " unnum=" F also "> 

<IPv4 address =" 192.168.1.1 " id=" id47505D0C16470" name=" MyFirewall:ifO:ip" 

nctmask=" 255.255.255.0 "/> 
<phys Address address ="00:17:f2:ca:cc:35" id="id47505D3816470" name=" 
MyFircwall:ifO:mac"/> 
</Interface> 

<Interface dyn=" True" i d=" id4 7 5 5 D 0D 1 64 70 " name=" i f 1 " unnum=" False" /> 
<Interface dyn=" False" id ="id47505D0F 16470" namc=" 1 " unnum=" False" 
unprotected =" F a 1 s e " > 
<IPv4 address=" 127.0.0.1" id=" id47505D10 16470" namc=" MyFirewall:10:ip" 
nctmask=" 255.255.0.0 "/> 
</ I n t e rface> 

<PoHcy id=" id47505D08 16470 "> 

<PolicyRule acti o n=" Deny" commcnt=" " dircctio n=" Both" disable d=" False" id 
"id47505ECE16470" position =" 0"> 
<Src ncg=" Falsc"> 

<ObjectRef r cf=" s y s i d " /> 
</Src> 

<Dst ncg=" Falsc"> 

<ObjectRef ref=" i d 4 7 5 5 C E 8 1 6 4 7 " /> 
</Dst> 

<Srv neg=" False"> 

<ServiceRef ref=" id47505D0216470"/> 
</Srv> 



<Itf ncg=" Falsc"> 

<ObjectRef r c f =" s y s i d " /> 
</ Itf> 

<Wlien ncg=" Falsc' : > 

<IntervalRef r c f =" s y s i d 2 " /> 
</When> 
</PolicyRule> 
</ Policy> 
</Firewall> 

As we can see, the Firewall clement includes the definition for three network 
interfaces and a firewall policy. 

Interface definitions are expressed as Interface elements. Interface ifl is 
dynamic and has no static IP address associated with it. Interfaces ifO and loO 
have static IP addresses assocated with them. These IP addresses are expressed 
as enclosing IPv4 elements. One may wonder why interface address was not 
specified as an attribute. The answer is that an interface could have more than 
one IP address assigned to it. 

The firewall policy is expressed as a Policy element, and may contain one or 
more PolicyRule elements. Because XML specification [6] does not guarantee 
clement order, policy rule ordering is implicitly specified via position attrbute 
which defines PolicyRule absolute order within enclosing Policy element. 

Direction and Action rule fields are specified via direction and action at- 
tributes of a PolicyRule. Each PolicyRule rule element contains Src, Dst, Srv, 
Itf, When sub-elements to specify Source, Destination, Service, Interface and 
Time Interval rule fields respectively. Each of these elements could contain one 
or more object references specifing their value. 

Each of the field's matching value could optionally be made negative by 
specifying neg attribute. For example listing 4 demonstrates a destination which 
is either an object with id A or B. Adding negation as shown on listing 5 changes 
the meaning so that the destination must be neither A nor B. 



Listing 4: Negation Example (withou negation) 



<Dst ncg=" False 


"> 




<ObjectRef 


rcf = 


A»/> 


<ObjectRef 


rcf = 


B»/> 


</Dst> 







Listing 5: Negation Example (with negation) 



<Dst neg="True"> 

<ObjectRef rcf="A"/> 
<ObjectRef rcf="B"/> 

</Dst> 



As we have seen, there are two major ways to express relationships between 
objects in the Firewall Builder XML. The first way is embedding - when one 
object definition is enclosed in the other object definition element. An example 
is an Interface embedded within a Firewall object, or a IPv4 object, embed- 
ded within an Interface object. The second method uses a reference, via the 
ObjectRef element. In this method, in place of the object which we are refer- 
ing to, we place an ObjectRef element, which has its ref attribute set to the 
value of id of the object we are reffcring to. We can see such references in Src 
and Dst elements of a PolicyRule referencing Network and UDPService objects 
respectively in the example above. 

2.3 Processing Model 

It is not sufficient to define just Data Model to be able to write a firewall 
policy. A data model implies certain semantics, defined as a processing model. 
Processing model differs from one firewall platform to another. We will define an 
abstract processing model to be used when defining policies of Abstract Firewall 
and later on we will map it to processing models of concrete firewall platforms. 

For each packet passing through a firewall, several processing stages are 
applied. It is optionally processed via NAT Rules and then filtered by Firewall 
Policy Rules. These stages can change the packet headers or even drop or reject 
the whole packet. 

While the sequence of NAT and filtering steps varies from platform to plat- 
form in real firewalls (see section 3.4 for disuccion), in Firewall Builder's abstract 
firewall model, it is fixed and processing is always done in the following order: 

1. Network Address Translation step is performed 

2. Firewall Policy is applied 

The packet is first matched towards all NAT rules, in the order they are 
defined by the user. A NAT rule "matches" if the rule original source, original 
destination and original service fields match the current packet and if it happens 
within an optional time interval specified in the rule, (any matching fields may 
be specified as Any - a wildcard which matches any value). A matched packet 
is modified by replacing its source, destination and service fields with translated 
source, translated destination and translated service from the rule. If some of 
translated source, translated destination or translated service is left empty by 
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the user, it means that the original value of this field should be preseved. If a 
packet has not matched any NAT rules, it will be processed further, unchanged. 

Next, the packet is matched towards all Policy rules in the order they are 
defined by user. For each packet the following fields are matched towards the 
rules: 

Source packet source address (IP or data link level) 
Destination packet destination address (IP or data link level) 
Service packet service (One of IP, UDP, ICMP service objects.) 
Interface interface via which this packet has arrived 

Direction direction of the packet, in respect to the firewall (Inbound or Out- 
bound) 

Any of these field could be excluded from matching if Any wildcard is spec- 
ified as the value in the rule. 

Once a packet has matched one of the rules, the action specified in the rule 
is performed. Possible values are: 

Accept the packet is permitted to pass through 

Deny /Drop the packet is silently dropped 

Reject the packet is rejected, notyfing the server via ICMP message 

Accounting the packet counter associated with this rule is incremented 

Although actual firewall implementations may vary in what happens once 
a packet is matched (see section 3.3 for examples), in the Firewall Builder's 
abstract firewall model semantics are well defined: 

For accept, deny and reject actions after the first rule is matched, 
the approriate action is performed and no further rule checks are 
performed. For accounting actions, after a counter value increase, 
the packet matching is continued against any remaining rules. 

After all rules have been processed and no accept, deny or reject action was 
invoked, the default policy is applied. While the default policy could be differ- 
ent in underlying firewall platforms (see section 3.2 for discussion), in Firewall 
Builder's abstract firewall model, the default policy is to perform a drop action 
on every packet. 
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2.4 Policy Verification and Optimization 



Even before the policy is compiled to concrete firewall syntax, there is certain 
processing which could be done on the abstract policy model. The two main 
areas are verification and optimization. Having well-defined processing model 
and a policy expressed in a stadartized form, a generic high-level policy analysis 
could be performed without needing to focus on the details of firewall platform 
implementation. 



2.4.1 Verification 

While the XML syntax validation towards the DTD ensured that there are no 
syntax errors in the document, it does not catch errors in semantics. 

For example, we found it useful to show users a warning when some policy 
rules will never be used. It is similar to unreachable code detection in program- 
ming languages. For example, let us assume there are two identical rules (with 
drop action), which differ only in the destination address field. The first rule has 
destiation address 1.2.3.4-/16 while the second rule has 1.2.3.4/32. Obviously, 
all packets which could possibly match the second rule, will be matched by the 
first rule first. We call this situation "rule shadowing" , saying that the first rule 
"shadows" the second one. We try to detect such situations and report them to 
the user, since they most likely signify an error in the user's policy definition. 

In addition to rule shadowing, in the future we can forsee other semantic 
errors which can be detected and reported to the user. This is one of the areas 
for the future research. 



2.4.2 Optimization 

There is a cost for executing each rule in a firewall. Long policies tend to affect 
firewall performance. It is very beneficial to try to optimize firewall policy by 
combining and reshuffling rules to make it shorter and hence more efficient. 

Common optimization techniques include removing unusued or redundant 
rules, grouping multiple rules into a single one, and in general to try to express 
the same policy with the fewer rules. 
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3 Platform-specific challenges 



Let us examine selected examples of platform specifics on pf, iptables and iphlter 
firewall platforms. All these problems are normally hidden from Firewall Builder 
users, because the firewall hides all these platform-specific differences from the 
user and generates platform-specific code to resolve these issues. 

3.1 Implicit vs. Explicit Interface Specification 

3.2 Default Policy 

What should a firewall do with a packet which matched none of the policy rules? 
Should it be allowed to pass through, or should it be discarded? 

In iptables default policy is a user-configurable option. 

In iphlter packets are also passed by default, unless it is compiled with 
IPFILTER.DEFA ULT. BLOCK option[7] . 

In pf packets are passed by default 

3.3 First vs. Last Policy Rule Matching 

In typical packet filter, a packet is matched towards a list of rules. It could either 
match or not match each rule. If a rule is matched, it makes a decision to permit 
this packet (accept) or not (reject or drop). There are two common matching 
strategies. In the first strategy, matching occurs until the first matching rule is 
found. We will call it first match 2 . Another strategy is to match all rules, then 
make a decision based on last match. We will call this strategy iast match 3 , 
iptables supports only the first match strategy. 

iphlter and pf both support last match strategy by default, unless quick 
rule keyword was specified. This keyword intstructs the firewall to stop further 
matching and use results from the current match as a final decision on whenever 
packet should be permitted to pass. 

3.4 NAT vs Firewall Rules Order 

Often a firewall will perform both packet filtering and network address transla- 
tion (NAT) functions. The obvious question is: in what order NAT and filtering 
rules are applied? Are addresses translated first and then filters are checked, 

2 This strategy is also sometimes refTered to as the "single-trigger" approach 
3 This strategy is also sometimes refTered to as "mutli-trigger" approach 
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or vice- versa? This makes a big difference, because if NAT is applied first, one 
should use already translated (not original) addresses in policy rules. 

iptables destinguish two kind of NAT rules: SNAT (source NAT) and DNAT 
(destination NAT). It could be said that DNAT is applied first, then packet 
filtering, and then SNAT. 

PIX, another popular firewall platform from CISCO performs packet filtering 
first and then NAT. 

Both ipGlter and pf perform address translation first and only then perform 
filtering functions. 4 

3.5 Negation 

Sometimes it is convenient to use negation in policy rules. For example, to 
specify condition like "if source address is not 1.2.3.4" . A more complex form 
of negation is to apply it to a group of addresses ( "if source address is not in 
{1.2.3.4, 10.20.30.40Y). 

iptables support single address negation: 

"Many flags, including the 's' (or 'source') and '-d' ('-destination') 
flags can have their arguments preceded by '!' (pronounced 'not') 
to match addresses NOT equal to the ones given. For example, 's 
! localhost' matches any packet not coming from localhost.'" [13] . 

However for address ranges, support for which is facilitated by modJprange 
module, negation is not suported. 

Both ipfilter supports negation (at least for addresses). No group negation 
support is provided. 

pf supports negation (at least for addresses). It also supports a limited 
case of group negation, when using tables. For example, the following fragment 
allows to pass all trafic from all addresses, except ones in the black list. 

table <blacklist> {1.2.3.4 , 10.20.30.40} 

pass in quick inet from any to ! <blacklist> keep state 

3.6 Addrress Range Emulation 

All firewalls allow the user to specify an individual IP address or CIDR block 
in the rules. However, sometimes it is convenient to specify an address range 

4 In case of pf: "The only exception to this rule is when the pass keyword is used within 
the nat rule. This will cause the NATed packets to pass right through the filtering engine." [2] 
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(from - to). 

iptables permits address ranges using iprange module. 
Both ipElter and pf do not support address ranges. 

3.7 Dymanic Interfaces 

Oftentimes, the IP address assigned to an interface is not known at the time of 
the policy definition. This is common with dynamic interface, which obtains its 
address using DHCP or a similar protocol. Abstract Firewall Policy allows the 
user to implement such intcfaccs in policy rules, in place of source or destination 
addresses. 

pf permits the use of inteface names in the rules, and will use current interface 
IP addresses at the time the rule is executed. 

ipfilter is using special 0/32 notation to refer to currently assigned interface 
IP address. 

In the case of iptables there is no way to refer to the current interface 
dynamically-assigned IP address in policy rules. 

4 Abstract Policy Compilation Techniques 

In this section we will briefly discuss some implementation approaches used to 
compile and deploy Abstract Firewall policy to a concrete firewall platform. 

An abstract firewall policy needs to be compiled into policy for the concrete 
firewall. Usually this requires certain transformations. While overall rule data 
structure remains rougly the same (source, destitatio, action, etc.), a target 
firewall platform puts various limitations to the allowed values, and sometimes 
even implies slightly different semantics. 

We found it convenient to perform policy transformation as a series of small 
steps. Each step could be viewed as a function, which takes as input a list of 
policy rules and outputs a modified list of such rules. Some of these transforma- 
tions are quite simple and could be reused between different firewall platforms. 
These transformation functions are called Rule Processors. An example of a 
rule processor could be one which takes a single rule with address ranges in the 
rule source address and converts it to a group of rules, which together perform 
the same function as the original rule, but each rule has a single CIDR block in 
a source address field. 



13 



5 Related Work 



There is a lot of related research in this area (see [9] for a good survey on the 
subject). 

Many approaches are concentrated on building an abstract security model, 
and then applying to to the firewall policies (either automated genetation or 
verification). Some models arc using UML, some build upon RBAC model. 

In our opinion, one of the problems with such approaches is the big repre- 
sentation gap between the model abstractions and the concrete firewall device 
processing and data model. Our approach is more pragmatic. Firewall Builder's 
abstract firewall model is very close to the one used in the many modern day 
firewall devices. This model is familiar to the most firewall administrators and 
easy to understand. Our model could act as intermediate representation be- 
tween high-level models and formal languages and concrete firewall policies. 

Al-Shaer et. al[3] present good formalization of firewall rules relationships 
and classification of the anomalies which should be detected during policy ver- 
ification. 

6 Conclusions 

In this paper we have presented in an overview form Firewall Builder's approach 
of corss-platform firewall management: the idea of an Abstract Firewall, the 
data and a processing model of such firewall. In a few examples we have shown 
the kind of challenges firewall adminstrators are facing when they are required 
to work with multiple firewall platforms. 

The definition of an abstract firewall model and policy definition language is 
a first, enabling step which allows us to develop and apply various policy anal- 
ysis and transformation techniques in a platform-independent manner. Policiy 
verification and optimization techniques, briefly touced upon in the section 2.4 
presents many interesting research challenges and opportunities. 

Firwall Builder data files could contain multiple firewalls sharing common 
utility objects (hosts, networks, etc.). This opens the opportunity for developing 
more sophisticated policy analysis tools, considering not only a single firewall 
but a network with several firewalls. Such a comprehensive distributed firewal 
model could be analyzed for inter-firewall anomalies as well as intra-Hrewall 
anomalies[3] . 

In the course of the project, we started to work on a formal model of policy 



14 



rules relationships. Such a model is required to implement non-trivial valida- 
tion and optimization techniques. Our initial thinking was along the lines of 
multi-dimensional space, where each rule field represents a dimension and a rule 
represents a figure. Each packet is represented as a point in this space. If it 
matches some rule, this point will be inside a figure represented by the rule. 
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Appendices 

A Firewall Builder DTD 

<?xml version=" 1.0" encoding="utf -8"?> 

<! — 

Firewall Builder Document Type Definition 
http : //www . f wbuilder . org/ 
Version: $Revision: 1.41 $ 

Authors: Friedhelm Duesterhoef t , Vadim Zaliva, Vadim Kurland, Tidei Maurizio 

TODD: 

1. Allow groups of unrelated objects. 



<! ENTITY 7, BOOLEAN " (False | True) "> 
<! ENTITY 7. STRING "CDATA"> 
<! ENTITY 7. NUMBER "CDATA"> 



Supported policy rule actions: 

Accept - accept the packet, analysis terminates 

Reject - reject the packet and send ICMP 'unreachable' or 
TCP RST back to sender, analysis terminates 

Deny - drop the packet, nothing is sent back to sender, 

Scrub - run the packet through normalizer (see 'scrub' in 
PF) , continue analysis 

Return - action used internally, meaning may depend on 

implementation of the policy compiler but generally 
the block of rules 



skip N rules down and ( 
internally . 



Used internally . 



Accounting - generate target firewall platform rule to count 
the packet and continue analysis. 

Modify - edit the packet (change some header values, like 

TOS bits) or mark it somehow if the kernel supports 
that (e.g. target MARK in iptables) 

Tag - put a tag on the packet or mark it somehow 

Pipe - send the packet to the userland process for inspectif 

Classify - classify the packet for QoS or traffic shaping 

Custom - platform-depended custom action 

Branch - branch to a subset of rules for inspection 



<! ENTITY 7, ACTION " (Accept | Reject | Deny I Scrub I Return | Skip | Continue | Accounting I Modify I Tag | Pipe | Classify | Custom | Branch I Route) "> 

< ! ENTITY 7. DIRECTION " (Inbound | Outbound | Both) "> 

<! ENTITY 7. IP ADDRESS " CDATA"> 

<! ENTITY 7. NETMASK " CD ATA " > 
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<! — Standard attributes presented in all nodes — > 
< ! ENTITY '/, STD.ATTRIBUTES ' 

name 7, STRING ; SREQUIRED 

comment '/.STRING; #IMPLIED 

id ID #REQUIRED 

ro '/.BOOLEAN; #IMPLIED 



<! — Standard attributes for all system nodes — > 
<! ENTITY 7, SYS .ATTRIBUTES ' 



**** Document structure, main groups. **** 



< ! ELEMENT FWObj ectDatabase (Library*)> 
< ! ATTLIST FWObj ectDatabase 

xmlns CDATA #FIXED "http : //www. fwbuilder. org/1 . 0/" 

version '/.STRING; #FIXED "2.1.14" 

lastModified '/.NUMBER; #IMPLIED 

id ID #REQUIRED 



< ! ELEMENT Library ( (AnyNetwork | AnylPService | Anylnterval I ObjectGroup | Host | Firewall | 
Network | IPv4IDNSName | AddressTable IphysAddress | AddressRange | ObjectRef | ServiceGroupl 
IPService I ICMPService | TCPService | UDPService | CustomService | ServiceRef | 
IntervalGroup I Interval | IntervalRef | Interface | Policy I NAT | PolicyRule | 
NATRule | Library I TagService ) * ) > 
<! ATTLIST Library 

7«STD .ATTRIBUTES ; 

color '/.STRING; JflMPLIED 



**** Document structure, Services. **** 

— > 

<! ELEMENT AnylPService EMPTY > 
<! ATTLIST AnylPService 

7.SYS.ATTRIBUTES; 

7«STD .ATTRIBUTES ; 

protocol.num '/.NUMBER; #FIXED "0" 

> 

<! — Reference to Services child — > 
<! ELEMENT ServiceRef EMPTY > 
<! ATTLIST ServiceRef 

ref IDREF #REQUIRED 

> 

< ! ELEMENT ServiceGroup (( ServiceGroup | IPService I ICMPService | TCPService | UDPService I CustomService | ServiceRef | TagService)* 
<! ATTLIST ServiceGroup 
7«STD .ATTRIBUTES ; 



**** Document structure, Objects. **** 

<! — Reference to Objects child — > 
<! ELEMENT ObjectRef EMPTY > 
<! ATTLIST ObjectRef 

ref IDREF #REQUIRED 

< ! ELEMENT ObjectGroup ( (ObjectGroup | Host | Firewall I Network | IPv4 1 DNSName | AddressTable | AddressRange | ObjectRef) *) > 
<! ATTLIST ObjectGroup 
7«STD .ATTRIBUTES ; 



This element will contain elements with platform specific 
options. 

<0ptions> 

<0ption name="optionl_name">Valuel</Option> 
<0ption name="option2_name">Value2</0ption> 
</0ptions> 

Since list of compilers is open (everybody could write his 
own compiler) we do not define content model for this element. 



<! ELEMENT Option ANY> 
<! ATTLIST Option 
name '/.STRING; #REQUIRED 
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ELEMENT PolicyRuleOption 


s (Qptio 


!*)> 




ELEMENT NATRule Opt ions 


(Dptio 


!*)> 




ELEMENT RoutingRuleOptic 


ns (Opti 


n*) 


< 


ELEMENT Firewall Opt ions 


(□ptio 


!*)> 


< 


ELEMENT Host Opt ions 


(Optio 


!*)> 


< 


ELEMENT Gateway Opt ions 


(Dptio 


!*)> 



**** Document structure, rest **** 



< ! ELEMENT NATRule (DSrc , ODst , 0Srv,TSrc ,TDst ,TSrv,When? , NATRuleOptions?, NAT?)> 
< ! ATTLIST NATRule 

id ID #REQUIRED 

disabled '/.BOOLEAN; "False" 

position '/.NUMBER; # REQUIRED 

comment '/.STRING ; #IHPLIED 



< ! ELEMENT When (IntervalRef*)> 
<! ATTLIST When 
neg '/.BOOLEAN; #REQUIRED 



< ! ELEMENT OSrc (ObjectRef *)> 
<! ATTLIST OSrc 
neg '/.BOOLEAN; #REQUIRED 



< ! ELEMENT ODst (ObjectRef *)> 
<! ATTLIST ODst 
neg '/.BOOLEAN; ((REQUIRED 



<! ELEMENT OSrv (ServiceRef *) > 
<! ATTLIST OSrv 
neg '/.BOOLEAN; ((REQUIRED 



< ! ELEMENT TSrc (ObjectRef *)> 
<! ATTLIST TSrc 
neg '/.BOOLEAN; #REQUIRED 



< ! ELEMENT TDst (ObjectRef *)> 
<! ATTLIST TDst 
neg '/.BOOLEAN; #REQUIRED 



< ! ELEMENT TSrv (ServiceRef *)> 
<! ATTLIST TSrv 
neg '/.BOOLEAN; ((REQUIRED 



< ! ELEMENT RoutingRule (RDst , RGtw, RItf , Rout ingRule Opt i ons ? , Routing?)> 
<! ATTLIST RoutingRule 

id ID ((REQUIRED 

disabled '/.BOOLEAN ; "False" 

position '/.NUMBER; # REQUIRED 

metric '/.NUMBER; "0" 

comment '/.STRING ; #IMPLIED 



<! ELEMENT RDst 
<! ATTLIST RDst 
neg '/.BOOLEAN; 



<! ELEMENT RGtw 
<! ATTLIST RGtw 
neg '/.BOOLEAN; 



<! ELEMENT RItf 
<! ATTLIST RItf 
neg '/.BOOLEAN; 



(ObjectRef *)> 
#REQUIRED 

(ObjectRef*) > 
#REQUIRED 

(ObjectRef*)> 
#REQUIRED 



<! ELEMENT PolicyRule (Src,Dst,Srv?,Itf?, When?, PolicyRuleDpt ions?, Policy?)> 
<! ATTLIST PolicyRule 

id ID #REQUIRED 

disabled '/.BOOLEAN; "False" 

position '/.NUMBER; # REQUIRED 

direction '/.DIRECTION; ((IMPLIED 

action '/.ACTION ; # REQUIRED 

log '/.BOOLEAN ; ((REQUIRED 

comment '/.STRING ; ((IMPLIED 
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<! ELEMENT Src 
< ! ATTLIST Src 
neg "/BOOLEAN; 



(ObjectRef*)> 
#REQUIRED 



< ! ELEMENT Dst (ObjectRef*)> 
<! ATTLIST Dst 
neg '/BOOLEAN; #REQUIRED 



< ! ELEMENT Srv (ServiceRef*)> 
<! ATTLIST Srv 
neg '/BOOLEAN; #REQUIRED 



< ! ELEMENT Itf (ObjectRef*)> 
<! ATTLIST Itf 
neg '/BOOLEAN; #REQUIRED 



hardware or physical address (MAC , DLCI etc . ) 

<! ELEMENT physAddress EMPTY > 
<! ATTLIST physAddress 

%STD_ ATTRIBUTES ; 

address '/.STRING; #REQUIRED 



<! ELEMENT IPv4 EMPTY > 

<! ATTLIST IPv4 
'/STD .ATTRIBUTES ; 
address '/.IPADDRESS ; #REQUIRED 
netmask '/.NETMASK; #REQUIRED 



<! ELEMENT DNSName EMPTY > 
<! ATTLIST DNSName 
'/STD .ATTRIBUTES ; 

dnsrec '/.STRING ; # REQUIRED 

run.time '/.BOOLEAN ; # REQUIRED 



< ! ELEMENT AddressTable ( (IPv4 | ObjectRef ) *) > 
<! ATTLIST AddressTable 
'/STD .ATTRIBUTES ; 

filename '/.STRING; # REQUIRED 

run.time '/.BOOLEAN ; # REQUIRED 



i have the following attributes 



physAddress 

■ security.level 

■ network.zone 
unprotected 

■ label 



:d address 

. have IP address , but 



interface has dynamically ai 
interface is unnumbered (doi 
may still have MAC address) 

interface serves as a bridge port on bridging firewall. 
The difference between bridge port and unnumbered interface 
is that compilers may use special modules or commands for 
bridge ports on platforms that support them, such as 
module physdev for iptables. 
this is management interface 
MAC address of this interface 



ID of the object representing network z< 
Skip this interface while assigning acci 
human-readable label of this interface 



lists or policy rules 



<! ELEMENT Interface (IPv4*, physAddres; 
<! ATTLIST Interface 
'/STD .ATTRIBUTES ; 

dyn '/.BOOLEAN ; # REQUIRED 

unnum '/.BOOLEAN ; #IMPLIED 

mgmt '/.BOOLEAN ; #IMPLIED 

bridgeport '/.BOOLEAN ; #IMPLIED 

security.level '/.NUMBER; # REQUIRED 

network.zone IDREF #IMPLIED 

unprotected '/.BOOLEAN ; #IMPLIED 

label '/.STRING ; #IMPLIED 



<! — Remote management information for Firewall, Host, Gateway — > 
<! ELEMENT Management (SNMPManagement? , FWBD Management? , PolicylnstallScript?) > 
< ! ATTLIST Management 
address '/IPADDRESS; # REQUIRED 
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<! — User-defined custom policy installation script for Firewall — > 
<! ELEMENT PolicylnstallScript EMPTY> 
< ! ATTLIST PolicylnstallScript 

enabled '/.BOOLEAN ; " False " 

command X STRING ; #IHPLIED 

arguments X STRING ; #IHPLIED 



<! — SNMP management information for Firewall, Host, Gateway — > 
<! ELEMENT SNMPManagement EMPTY > 
<! ATTLIST SNMPManagement 

enabled '/.BOOLEAN ; " False " 

snmp_read_ community '/.STRING; #IMPLIED 

snmp_write_community '/.STRING ; #IMPLIED 



<! — FWBD management information for Firewall, Host, Gateway — > 
< ! ELEMENT FWBDManagement (PublicKey?)> 
<! ATTLIST FWBDManagement 

enabled '/.BOOLEAN ; " False " 

port 7, NUMBER ; # REQUIRED 

identity '/.STRING ; # REQUIRED 



<! — Remote FWBD public key for Firewall, Host, Gateway — > 
< ! ELEMENT PublicKey (#PCDATA)> 

<!ELEMENT Host (Interface*, Management?, HostOptions?)> 
<! ATTLIST Host 
XSTD.ATTRIBUTES ; 

host.OS '/.STRING ; #IMPLIED 



<! ELEMENT AnyNetwork EMPTY> 
<! ATTLIST AnyNetwork 

7,SYS_ATTRIBUTES; 

7,STD_ATTRIBUTES ; 

address 7, IP ADDRESS ; #FIXED "0.0.0.0" 

netmask '/.NETMASK ; #FIXED "0.0.0.0" 



<! ELEMENT Network EMPTY> 

<! ATTLIST Network 
7,STD_ATTRIBUTES ; 
address '/.IP ADDRESS ; #REQUIRED 
netmask '/.NETMASK ; #REQUIRED 



<! ELEMENT AddressRange EMPTY > 
<! ATTLIST AddressRange 
7.STD_ATTRIBUTES ; 

start.address XIPADDRESS; # REQUIRED 
end.address XIPADDRESS ; #REQUIRED 



<! ELEMENT ICMPService EMPTY> 

<! ATTLIST ICMPService 
XSTD.ATTRIBUTES ; 
code '/.NUMBER; #REQUIRED 
type '/.NUMBER; #REQUIRED 



<! ELEMENT TagService EMPTY> 
<! ATTLIST TagService 

7.STD_ATTRIBUTES ; 

tagcode '/.STRING; #REQUIRED 



<! ELEMENT IPService EMPTY> 
<! ATTLIST IPService 
XSTD.ATTRIBUTES ; 



protocol.: 
lsrr 



l XNUMBER; # REQUIRED 

XB00LEAN; #IMPLIED 

XB00LEAN; #IMPLIED 

XB00LEAN; #IMPLIED 

XB00LEAN; # IMPLIED 

XB00LEAN; #IMPLIED 

XB00LEAN; #IMPLIED 



<! ELEMENT TCPService EMPTY> 
<! ATTLIST TCPService 
7.STD_ATTRIBUTES ; 

dst_range_end '/.NUMBER ; #REQUIRED 

dst .range .start XNUMBER; #REQUIRED 

urg.flag '/.BOOLEAN ; #REQUIRED 

ack.flag XB00LEAN; #REQUIRED 

psh.flag '/.BOOLEAN ; # REQUIRED 

rst.flag '/.BOOLEAN; #REQUIRED 

syn.flag XB00LEAN; # REQUIRED 
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fin.flag '/.BOOLEAN; # REQUIRED 

urg_f lag_mask '/.BOOLEAN; #REQUIRED 

ack.f lag.mask '/.BOOLEAN; # REQUIRED 

psh.f lag.mask '/.BOOLEAN; # REQUIRED 

rst_f lag_mask '/.BOOLEAN; # REQUIRED 

syn_f lag_mask '/.BOOLEAN; #REQUIRED 

f in_f lag_mask '/.BOOLEAN; #REQUIRED 

src_range_end '/.NUMBER; #REQUIRED 

src .range .start '/.NUMBER; #REQUIRED 

established '/.BOOLEAN; #IMPLIED 



<! ELEMENT UDPService EMPTY > 
< ! ATTLIST UDPService 
%STD_ ATTRIBUTES ; 

dst_range_end '/.NUMBER; # REQUIRED 

dst.range.start '/.NUMBER; #REQUIRED 

src.range.end '/.NUMBER; # REQUIRED 

src_range_start '/.NUMBER; #REQUIRED 



<! ELEMENT CustomService Command (#PCDATA)> 
<! ATTLIST CustomService Command 
platform '/.STRING; #REQUIRED 



<! ELEMENT CustomService (CustomServiceCommand*)> 
<! ATTLIST CustomService 
*/,STD .ATTRIBUTES ; 



< ! ELEMENT Gateway (Interface* , Management?, GatewayOptions?)> 
<! ATTLIST Gateway 
7, STD .ATTRIBUTES ; 

address '/.IP ADDRESS ; # REQUIRED 

host.OS '/.STRING ; #IMPLIED 



<! ELEMENT Firewall (NAT 
<! ATTLIST Firewall 

*/,STD .ATTRIBUTES ; 

platform 



iiosi 



.OS 



Policy , Routing , Interface* , Management? , FirewallOptii 



'/.STRING; 
'/.STRING; 
'/.STRING; 
'/.NUMBER; 
'/.NUMBER; 
'/.NUMBER; 
'/.BOOLEAN ; 



# REQUIRED 
#IMPLIED 
#IMPLIED 
#IMPLIED 
#IMPLIED 
#IMPLIED 
#IMPLIED 



< ! ELEMENT NAT (NATRule*)> 
<! ATTLIST NAT 
id ID #REQUIRED 



< ! ELEMENT Policy (PolicyRule*) > 
<! ATTLIST Policy 
id ID #REQUIRED 



< ! ELEMENT Routing (RoutingRule*)> 
<! ATTLIST Routing 
id ID #REQUIRED 



<! — Time — > 



< ! ELEMENT IntervalGroup ( (IntervalGroup | Interval I IntervalRef ) *) > 
<! ATTLIST IntervalGroup 
*/,STD .ATTRIBUTES ; 



<! — Reference to time interval — > 
<! ELEMENT IntervalRef EMPTY > 
<! ATTLIST IntervalRef 

ref IDREF #REQUIRED 



:! ELEMENT Interval EMPTY > 
:! ATTLIST Interval 



*/,STD .ATTRIBUTES ; 


f rom.second 


'/.NUMBER 






'/.NUMBER 




from. hour 


'/.NUMBER 




f rom.day 


'/.NUMBER 




f rom.month 


'/.NUMBER 




f rom.year 


'/.NUMBER 




f rom.weekday 


'/.NUMBER 





21 



to_minute 
to_hour 

to_month 

to_weekday 



'/.NUMBER ■ 
'/.NUMBER 
'/NUMBER- 
'/NUMBER 
'/NUMBER 
'/NUMBER 



<! ELEMENT Anylnterval EMPTY > 
< ! ATTLIST Anylnterval 

'/SYS .ATTRIBUTES ; 

7„STD_ATTRIBUTES ; 



f rom_second 


'/NUMBER 


#FIXED 


f rom_minute 


'/NUMBER 


#FIXED 


f rom_hour 


'/NUMBER 


#FIXED 


f rom_day 


'/NUMBER 


#FIXED 


f rom_month 


'/NUMBER 


#FIXED 


f rom_year 


'/NUMBER 


#FIXED 


f rom_weekday 


'/NUMBER 


#FIXED 



to 




'/NUMBER 


#FIXED 




minute 


'/NUMBER 


#FIXED 


to 




'/NUMBER 


#FIXED 






"/NUMBER 


#FIXED 


to 


month 


'/NUMBER 


#FIXED 




year 


'/NUMBER 


#FIXED 


to 


weekday 


'/NUMBER 


#FIXED 



